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ABSTRACT 



A method for maintaining IPCP address negotiations in a 
wireless communication network is presented. The method 
includes a communication device receiving a message 
requesting an IP address, such as a Config-Request message, 
from a terminal device, which is coupled to the communi- 
cation device. The communication device then generates a 
message requesting an IP address, such as a Config-Request 
message, and forwards it to a peer (IWF) within the network. 
The communication device then determines whether it has 
received an assigned IP address from the IWF in response to 
the IP address request message. In response to determining 
that the communication device has not received the assigned 
IP address from the IWF, the communication device trans- 
mits a message with an arbitrary IP address, such as a 
Configure-Nak message, to the terminal device. The arbi- 
trary IP address contained within the message will be 
rejected by the communication device, upon receipt of future 
Configure -Requests containing the arbitrary address. This 
triggers the terminal device to keep transmitting additional 
IP address request messages until the communication device 
has received the assigned IP address. 

32 Claims, 4 Drawing Sheets 
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METHOD OF AVOIDING PPP TIME-OUTS Other support is made possible by applying various 

DURING IPCP NEGOTIATIONS well-known protocols to control, manage, or otherwise 

facilitate different aspects of wireless communications. For 

BACKGROUND OF THE INVENTION example, the life-blood of the Internet infrastructure, the 

. 5 Internet Protocol (IP), has been incorporated in many wire- 

1. Field of the Invention less communication services to accommodate packet- 
This invention generally relates to the field of wireless orienled ^ ^ w tocol dfies me address ing 

communications. More particularly, the present invention and routi of kcts (datagrams) bctwecn host computers 

relates to a novel method of avoiding time-outs to sustain and ^ defifled m Request Fof Comment 791 (RFC 791) 

IPCP address negotiations. 1Q entitled> "INTERNET PROTOCOL DARPA INTERNET 

2. Description of Related Art PROGRAM PROTOCOL SPECIFICATION," published 
Recent innovations in wireless communication and September 1981. 

computer-related technologies, as well as the unprecedented ^ Ip ^ fc a netW0fk , QCol ^ _ 
growth of Internet subscribers, have paved the way for data ^ , p kcts for (ransmissioiL Addressing and 
mobile computing. In fact the popularity of mobile com- 15 routi & m the header of the packet . IP 
putmg has placed greater demands on the current Internet headefS comain 32 _ bit addresses lhat idemify ^ 
infrastructure to provide mobile users with more support. A and recciving hosts> addresses are used by interme- 
dial part of meeting these demands and providing users diate {Q ^ a ± thr fa ^ netwQrk for tQe 
with the necessary support is the use of Code Division ket towards its ultimate dcstination at the 
Multiple Access (CDMA) technology in wireless commu- ^ addfess ^ the Tp protocol aUows packets originating at 
nicauon systems. any mternet m me world to De roulec i to anv ol her 
CDMA is a digital radio-frequency (RF) channelization Internet node in the world. 

technique defined in the Telecommunications Industry a «u n i i • * a * ■ i 

A ... i j « ■ a Another well-known protocol incorporated in wireless 

Association/Electronics Industries Association Intenm . * • *i_ n • . * n • * n . * 

Staadard-95 (TIA/EIA IS-95), entitled "MOBILE 25 ^""TT T*™ *h ? ^ 1 T , 

STAnON-BASE STATION COMPATIBILITY STAN- ^^p 0 ' 000 , 1 ' 1Ch J K>v, f s : f*' " f 

DARD FOR DUAL-MODE WIDEBAND SPREAD SPEC- ^^kT^Fp S eZ.fi "^F POI^TO 

Tnn»i/>TTiTiT AnovPTTii.. uv u -i* t 1 mni j Comments I60I (RFC lool), entitled THE POINT-TO- 

TRUM CELLULAR SYSTEM , published m July 1993 and POINT PROTOCOL (PPP)", published July 1994. 

herein incorporated by reference. Wireless communication ^ . „ , , , r 

systems employing this technology assign a unique code to 30 Essentially, the PPP protocol specifies a method for 

communication signals and spread these communication transporting multiprotocol datagrams over point-to-point 

signals across a common (wideband) spread spectrum band- links ™? contains ^ m f \ components: a method of 

width. As long as the receiving apparatus in a CDMAsystem encapsulatmg multi-protocol datagrams; a Link Control 

has the correct code, it can successfully detect and select its °\ ( LCP ) for establishing, configuring, and testing a 

communication signal from the other signals concurrently 35 data hnk an <* a famd y of Network Control 

transmitted over the same bandwidth. The use of CDMA Protocols (NCPs) for establishing and configuring different 

produces an increase in system traffic capacity, improves network-layer protocols. 

overall call quality and noise reduction, and provides a In an eff o rt t0 provide a host of services on wireless 

reliable transport mechanism for data service traffic. communication systems, various standards have been devel- 

FIG. I illustrates the basic elements of such a wireless 40 °P ed t0 accommodate the wireless data transmission 

data communication system 100. Artisans of ordinary skill between the TE2 device 102 and the IWF 108. For example, 

will readily appreciate that these elements, and their the TIA/EIA IS707.5 standard, entitled "DATA SERVICE 

interfaces, may be modified, augmented, or subjected to OPTIONS FOR WIDEBAND SPREAD SPECTRUM SYS - 

various standards known in the art, without limiting their TEMS: PACKET DATA SERVICES," published February 

scope or function. System 100 allows a mobile terminal 45 1 998, and herein incorporated by reference, defines require - 

equipment, TE2 device 102 (e.g., the terminal equipment ments for su PP ort of packet data transmission capability on 

such as laptop or palmtop computer) to communicate with TIA/EIA IS95 systems and specifies a suite of packet data 

an Interworking Function (IWF) 108. System 100 includes bearer services. 

a wireless communication device, MT2 device 104 (e.g., In particular, the IS-707.5 standard provides certain 

wireless telephone), and a Base Station/Mobile Switching 50 packet data service modes that may be used to communicate 

Center (BS/MSC) 106. The IWF 108 serves as a gateway between the TE2 device 102 and IWF 108 via BS/MSC 106. 

between the wireless network and other networks, such as In doing so, IS-707.5 introduces the Network Model, which 

the Public Switched Telephone Network or wireline packet provides a specific mode of operation. The Network Model 

data networks providing Internet-or Intranet-based access. represents the situation where a first PPP link is set up 

An L interface couples IWF 108 to BS/MSC 106. Often the 55 between the TE2 device 102 and the MT2 device 104, and 

IWF 108 will be co-located with the BS/MSC 106. The TE2 a second PPP link, independent of the first, is set up between 

device 102 is electronically coupled to the MT2 device 104 the MT2 device 104 and the IWF 108. This model makes the 

via the Rm interface. The MT2 device 104 communicates MT2 device 104 responsible for unframing any received 

with the BS/MSC 106 via the wireless interface U m . The PPP packets and re-framing them before forwarding them to 

TE2 device 102 and the MT2 device 104 may be integrated 60 meir final destination as well as providing mobility man- 

into a single unit (e.g., MT0 device) or may be separated out, agement and network address management, 

as in the case of an installed mobile phone unit in which a FIG. 2 illustrates the protocol stacks in each entity of the 

laptop is the TE2 device 102 and the transceiver is the MT2 IS-707.5 Network Model. At the far left of FIG. 2 is a 

device 104. It is important to note that, as indicated by FIG. protocol stack, shown in conventional vertical format, 

(2, the combination of the TE2 device 102 and the MT2 65 depicting the protocol layers running on the IKlievice 1Q2> 

! device 104, whether integrated or separate, is generally (e.g., thejnobile terminal^ptpp or palmtop computer) . The 

preferred to as a mobile station (MS) 103. TE2 protocol stack is illustrated as being logically connected 
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to the MT2 device 104 protocol stack over the K m interface. 
The MT2 device 104, is illustrated as being logically con- 
nected to the BS/MSC 106 protocol stack over the V m 
interface. The BS/MSC 106 protocol stack is, in turn, shown 
as being logically connected to the IWF 108 protocol stack : 
over the L interface. 

As an illustration, the protocols depicted in FIG. 2, 
operate as follows: the PPP layer on the TE2 102 device 
associated with the Rm interface (i.e., ??? R 208)^^0^^ 
packets from the upper layer pro tocols 20 4~and.me rerwo'ric 1 
layer IPprotocol^6. vjhe PPP^ layer 208 then transmits the 
packetsTcrosslhe R m interface using an applicable protocol, 
such as, for example, the TIA/EIA 232-F protocol 210, and 
the_ packets . arc„rcceived;byime^ 

port on the MT2 devicelO&Jhe nA/EIA : 232-F standard 15 
is defined in "INTERFACE BETWEEN DATA TERMINAL 
EQUIPMENT AND DATA CIRCUIT-TERMINATING 
EQUIPMENT EMPLOYING SERIAL BINARY DATA 
INTERCHANGE", published in October 1997 and herein 
incorporated by reference. It is to be understood that other 20 
standards or protocols known to artisans of ordinary skill in 
the art may be used to define the transmission across the R m 
interface. For example, other applicable R^. interface stan- 
dards include, the "UNIVERSAL SERIAL BUS (USB) 
SPECIFICATION, Revision 1.1", published in September 25 
1998, and the "BLUETOOTH SPECIFICATION VERSION 
1.0A CORE, published in July 1999, both incorporated by 
reference. 

The TIA/EIA 232-F protocol 212 on the MT2 device 104 
receives the packets from the TE2 device 102 and passes 30 
them to the PPP* layer 213 of the MT2 device 104. The 
PPP* layer 213 unframes the packets encapsulated in the 
PPP frames and typically, when a data connection is up, 
layer 213 transfers the packets to the PPP layer associated 
with the U m . interface (i.e., PPP^ layer 217). PPP^ layer 217 
formats the packets in PPP frames for transmission to a 
PPP^peer located in the IWF 108. The Radio Link Protocol 
(RLP) 216 and IS-95 protocol 214, both of which are well 
known in the art, are used to transmit the packet- 
encapsulated PPP frames to the BS/MSC 106 over the U m 
interface. The RLP protocol 216 is defined in the IS -707. 2 
standard, entitled "DATA SERVICE OPTIONS FOR WIDE- 
BAND SPREAD SPECTRUM SYSTEMS: RADIO LINK 
PROTOCOL", published in February 1998 and the IS-95 
protocol is defined in the IS-95 standard identified above. 

As stated above, the PPP* protocol 213 transfers the 
packets to the V?P V protocol 217 when a data link connec- 
tion is established. RFC 1661 provides that Link Control 
Protocol (LCP) packets must be exchanged and negotiated 
over each PPP link (i.e., PPP* and PPP^ ) in order to 
establish, configure, and test the data link connection. 

Once the LCP packets are exchanged, the link options 
negotiated, and the data link connection established, a 
network layer connection must be established between the 55 
jTE2 device 102 and the IWF 108. Such a connection 
i employs protocols 206, 212, 218, 230, that include, for 
j example, the IP protocol. (The negotiajmgriconfig^™^!^ 
xnabling, and disabling of the IP protocol on both ends of the*^ 
TPRlinks is provided by the well-known imemet Protocol^Q 
'j^bl^l-jfto^ a part of a family of 

Network Control Protocols (NCPs) included in the PPP 
protocol and is described in Request for Comment (RFC) 
[rl332, "THE PPP INTERNET PROTOCOL CONTROL 
^ PROTOCOL (IPCP)", published in May 1992. 65 
I The IPCP protocol employs the standard PPP Configure - 
Request, Configure-Ack, and Configure-Nak messages to 



35 



40 



45 



50 



negotiate various options, including the request and desig-. 
nation of IP addresses. IPCP provides that a requested 
requesting an IP address, generates a Configure-Request 
message, which contains a particular address. If the particu- 
lar IP address is acceptable, a Configuration-Ack message is 
sent by a peer to the requester. If the particular IP address is 
not acceptable, then the peer sends a Configure-Nak mes- 
sage containing a suggested IP address. The requester then 
transmits a new Configure-Request message with the sug- 
gested IP address and the peer responds with a Configure-i 
Ack. 

It is only possible to assign single IP address across the 
PPP^ and PPP* links as there is no mechanism in IPCP to 
assign more than one address. This means that the IP address 
that is assigned from the IWF over PPPy, must further be 
assigned to the TE2 over PPP/e- In the Network Model, while 
IPCP address negotiations can occur separately for both the 
R m interface and the U m interface. As such, the MT2 device 
104 must first negotiate an IP address over the \J m interface 
with the IWF 108 at one end of the PPP^ link, before the 
address can be assigned to the TE2 device 102 at the other 
end of the PPP* link. * 

The consummation of IPCP address negotiations may be 
obstructed, however, by operational delays. For example, 
such delays can occur if the link between the MT2 device 
104 and the IWF 108 is slower than the link between the TE2 
device 102 and the MT2 device 104. As such, there exists a 
possibility that IPCP address negotiations are reached faster 
on the 1^ link than on the U m link. The TE2 device 102 may, 
therefore, request an IP address from the MT2 device 104, 
which cannot be granted because the MT2 device 104 has 
not completed the requisite address negotiations on the U m 
link to render an IP address from the IWF 108. Although the 
TE2 device 102 is capable of waiting for the MT2 device 
104 to eventually render an IP address, there are 
implementation-specific time-outs on the TE2 device 102, 
which can cause the TE2 device 102 to abort the IP address 
request, and therefor PPP negotiations altogether. 

Another example of operational delays occurs when the 
IWF 108 has to get the IP address, which will eventually be 
assigned to the TE2 device 102, from some other entity 
before it can pass it on to the MT2 device 104. In doing so, 
it may take several seconds before the MT2 device 104 
receives the IP address. 

By way of example, it is noted that some applications 
running on the TE2 device 102 allow the TE2 device 102 to 
generate Configure-Request messages every 3 seconds for 3 
attempts before the TE2 device 102 times out. In such cases, 
if it takes more than a total of 9 seconds to receive an IP 
address, the TE2 device 102 aborts the address request. 
Clearly, either of the two scenarios noted above can generate 
delays that can lead to the TE2 device 102 to abort prema- 
turely. 

Therefore, what is needed is a novel method of avoiding 
time-outs to sustain IPCP address negotiations. 

SUMMARY OF THE INVENTION 

The present invention addresses the need identified above 
by providing a novel method of avoiding time-outs to 
sustain IPCP negotiations. 

Methods consistent with the principles of the present 
invention as embodied and broadly described herein include 
a communication device receiving a message requesting an 
IP address, such as a Config-Request message, from a 
terminal device which is coupled to the communication 
device. The communication device then determines whether 
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it has received an assigned IP address from a peer (i.e. IWF) In block B315, the MT2 device 104 determines whether^ 

in response to the IP address request message. In response to it has received an IP address, assigned by the IWF 108, in 

determining that the communication device has not received response to the Configure-Request message from the TE2 

the assigned IP address from the IWF, the communication device 102. If it has not, the MT2 device 104 advances to^ 

device transmits a message with an arbitrary IP address, such 5 block B320, where it rejects the EP address contained within 

as a Configure-Nak message, to the terminal device. The ^ Configure-Request message and transmits a Configure- 

arbitrary IP address contained within the message will be Nak message with an arbitrary IP address. (See, reference 

rejected by the communication device, which triggers the ™**<* * m ^^l^ IPadd 1 r ^ f, aQ ad , dreSS 

terminal device to keep transmitting additional IP address * a ' ^ ^ e f d "if U £? 

request messages until the communication device has 10 «"«»* ^^^Jf 5536 ^, ^ 

^ . , . & . Jtn address, the MT2 device 104 loops back to block B310 to 
received the assigned IP address. . . 1T »,™ ~ * r, c t . 

^ await another IP CP Configure-Request message from the 

BRIEF DESCRIPTION OF THE DRAWINGS TE1 dcvicc 102 > ^th the arbitrary IP address. Because the 

arbitrary IP address is not the IP address assigned by the IWF 
The accompanying drawings, which are incorporated in the MT2 device 104 is directed back to block B320 

and constitute a part of this Specification, illustrate an where it, once again, rejects the IP address contained within 

embodiment of the invention and, together with the the Configure-Request message and transmits a Configure- 

description, explain the objects, advantages, and principles Nak message with an arbitrary IP address. The arbitrary 

of the invention. In the drawings: address may be the same address as the previous iteration or 

FIG. 1 is a high level block diagram depicting various ^ may be a different address. The loop created by the series of 

elements of a wireless communication system. blocks B310-B315-B320 iterate until the MT2 device 104 

FIG. 2 schematically describes the protocol stacks of a determines that it has received an IWF 108-assigned IP 

wireless communication system. address. By engagmg the TE2 device 102 and triggering it 

™^ _ A . a , , • _ o , to generate Configure-Req messages, the MT2 device 104 

FIG. 3Ais a flow-chart diagram describing an embodi- 5 , , . 1JM r~L ' . . . . 

, t prevents the TE2 device 102 from timing out, thereby 

ment of the invention. 25 r . , . . T4 ° . , . ' 

sustammg the IPCP address negotiations. It would also be 

FIG. 3B is a protocol-message flow diagram describing possible to i ntro duce a delay into the loop which will reduce 

the operation of an embodiment of the invention. thc number of messa g C s exchanged between the MT2 device 

nrTATI t->t-\ nrcmiirnrtM r\r? tuc 104 and the TE2 device 102. 

DETAILED DESCRIPTION OF THE _ , , , , , ._ , w __ , . . a 

PREFERRED EMBODIMENTS 30 Returning back to block B315, if the MT2 device 104 (\ 

determines that it has received an IWF 108-assigned IP 

The following detailed description of the embodiments of address, the MT2 device 104 progresses to B325 where it 

the present invention refers to the accompanying drawings transmits a Configure-Nak message containing the assigned 

that illustrate these. Other embodiments are possible and pp address to the TE2 device 102. (See, reference numeral 

modifications may be made to the embodiments without ^ c). The MT2 device 104 then receives, in block B330, a 

departing from the spirit and scope of the invention. Configure-Request message with the assigned IP address 

Therefore, the following detailed description is not meant to from the TE2 device 102. (See, reference numeral D). \j 
limit the invention. Rather the scope of the invention is ^ MT2 device 104 advances to block B335, where iK\ 

defined by the appended claims. transmits a Config-Ack message to the TE2 device 102, to 1 1 

It will be apparent to one of ordinary skill in the art that ^ acknowledge the Configure-Request message from the TE2] j 

an embodiment of the present invention, as described below, device 102. (See, reference numeral E). In block B340, the; j 

may be realized in a variety of implementations, including MT2 device 104 then transmits the EPCP options negotiated I 

the software, firmware, and hardware of the entities illus- over the U m link with the IWF 108 to the TE2 device 102! > 

trated in the figures (i.e., TE2 device 102, MT2 device 104, (See, reference numeral F). The MT2 device 104 then ! 

BS/MSC 106 and IWF 108). The actual software code or 45 receives, in block B345, a Config-Ack message from the j 

control hardware used to implement the present invention is TE2 device 104, acknowledging the options in use by the ' 

not limiting of the present invention. Thus, the operation and IWF 108-assigned IP address. (See, reference numeral G). It 

behavior of the present invention will be described without is noted that the processes in blocks B340 and B345 are not 

specific reference to the actual software code or hardware strictly required, as the MT2 device 104 could send any 

components. Such non-specific references are acceptable 50 arbitrary IPCP values to the TE2 device 102:since7allpackets \ 

because it is clearly understood that a person of ordinary are being framed* and unframed:thraugh3m^MT2-devi£e^ 

skill in the art would be able to design software and control 104 

hardware to implement the embodiment of the present Thus, this embodiment is capable of avoiding 

invention based on the description herein. implementation-specific time-outs by supplying the TE2 

FIG. 3A is a flow-chart diagram depicting an embodiment 55 device 102 with Configure-Nak messages, which contain 

of the present invention and FIG. 3B is a protocol-message arbitrary IP addresses that will be rejected by the MT2 

flow diagram describing the operation of an embodiment of device 104. The Configure-Nak messages trigger the TE2 

the invention. As indicated in FIG. 3 A, the MT2 device 104, device 102 into generating Configure-Request messages, 

in block B305, commences PPP negotiations across the U„, This interplay continues until the MT2 device 104 receives 

interface with the IWF 108. This event is triggered by the 60 the IWF 108-assigned IP address and forwards this IP 

start of LCP negotiations on the R m interface, as depicted in address to the TE2 device 102 in a Configure-Nak message. 

FIG. 3B (see reference numeral A). In this manner, the TE2 device 102 is precluded from 

In block B310, the MT2 device 104 waits until it has prematurely aborting due to implementation -specific tim- 

received an IPCP Configure-Request message from the TE2 eouts and PPP negotiations are sustained, 
device 102. Once the MT2 device 104 has received a 65 The foregoing description of preferred embodiments of 

Configure-Request message from the TE2 device 102, the the present invention provides illustration and description, 

MT2 device 104 progresses to block B315. but is not intended to be exhaustive or to limit the invention 
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to the precise form disclosed. Modifications and variations 10. The method of claim 9, said arbitrary IP address 

are possible consistent with the above teachings or may be message is an IPCP Configure-Nak message containing one 

acquired from practice of the invention. Accordingly, the of a plurality of arbitrary IP addresses that said communi- 

scope of the invention is defined by the claims and their cation device will reject. 

equivalents. s 11. The method of claim 10, wherein said ascertaining 

What is claimed: whether said interworking function has assigned an IP 

1. A method for maintaining IP address negotiations in a address in response to said IP address request message is 
wireless communication network, said method comprising: determined by identifying whether said communication 

receiving, in a communication device, a message request- device has received an IPCP Configure-Ack message con- 
ing an IP address from a terminal device, said terminal 10 taking an ip address from said interworking function, 
device coupled to said communication device; 12 . The method of claim 11, wherein said assigned IP 

generating, in said communication device, a message address message is an IPCP Configure -Nak message con- 
requesting an IP address from said communication taining said assigned IP address provided by said interwork- 
network in response to said IP address request message; m g function. 

and !5 13. The method of claim 12, wherein said IP address 

determining whether said communication device has request message with said assigned IP address is an IPCP 

received an assigned IP address from said communi- Configure-Request message containing said assigned IP 

cation network, wherein, in response to determining address. 

that said communication device has not received said 14. The method of claim 13, wherein said message 

assigned IP address, said communication device repeat- 20 acknowledging said IP address request message with said 

edly transmits a message with an arbitrary IP address to assigned IP address is an IPCP Configure-Ack message, 

said terminal device to trigger said terminal device to 15. The method of claim 14, wherein said message 

respond by transmitting IP address request messages acknowledging said receipt of said assigned IP address to 

with said arbitrary IP address and said communication said interworking function is an IPCP Configure-Ack mes- 

device rejects said arbitrary IP address in said IP 25 sage. 

address request messages until said communication 16. The method of claim 15, further including introducing 

device has received said assigned IP address from said a delay of a predetermined duration to reduce the number of 

communication network. times said communication device repeatedly transmits said 

2. The method of claim 1, wherein said generating arbitrary IP address message and the number of times said 
includes, forwarding said IP address request message from 30 terminal device responds with said IP address request racs- 
said communication device to an interworking function sages containing said arbitrary IP address. 

included in said communication network, and 17. A mechanism for mamtaining IP address negotiations 

negotiating with said interworking function to secure said in a wireless communication network, said mechanism 

assigned address based on said IP address request comprising: 

message. 35 a terminal device; and 

3. The method of claim 2, wherein said determining a communication device coupled to said terminal device, 
includes ascertaining whether said interworking function ^ communication device receiving an IP address 
has provided said assigned IP address m response to said IP rcqucst message ^ ^ terminal device and, in 
address negotiations. response, said communication device transmitting an 

4. The method of claim 3, wherein, in response to 40 ip address request message to said communication 
determining that said communication device has received network; 

said assigned IP address, said communication device trans- , ., . . , . , . . 

& .j. . 1 Jm t . j . - . wherein, said communication device determines whether 

mits a message with said assigned IP address to said terminal j • 1 m 11 ? „ . , „ 

. . & & lt n as received an assigned IP address from said com- 
device 

CTH. ti. j e i • a u • • * ^ munication network, and 

5. The method of claim 4, wherein, in response to 45 

transmitting said assigned IP address message to said ter- wherein, in response to determining that said communi - 

minal device, said communication device receives an IP cation device has not received said assigned IP address, 

address request message with said assigned IP address from ^ communication device repeatedly transmits a mes- 

said terminal device ^m an arDlu * arv IP address to said terminal device 

6. The method of claim 5, wherein, in response to 50 t0 trigger said terminal device to respond by transmit- 
receiving said IP address request message with said assigned tin S ff addrcss rcc l uest messages with said arbitrary IP 
IP address from said terminal device, said communication MlQSS and said communication device rejects said 
device transmits a message acknowledging said IP address arbitrary IP address in said IP address request messages 
request message to said terminal device. miU ™ id communication device has received said 

7. The method of claim 6, wherein, in response to 55 assigned IP address from said coinmunication network, 
transmitting a message acknowledging said IP address 18 - ^ mechanism of claim 17, wherein said wireless 
request message to said terminal device, said communica- communication network an interworking function and said 
Hon device transmits a message with configuration options communication device transmitting an IP address request 
from said interworking function. message to said communication network includes, 

8. The method of claim 7, wherein, in response to 60 forwarding said IP address request message from said 
transmitting said message with configuration options from communication device to said interworking function, 
said interworking function, said communication device and 

receives a message acknowledging receipt of said assigned negotiating with said interworking function to secure said 

IP address by said terminal device to said interworking assigned address based on said IP address request 

function, 65 message. 

9. The method of claim 8, wherein said IP address request 19. The mechanism of claim 18, wherein said communi - 
message is an IPCP Configure-Request message. cation device determines whether it has received an assigned 
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IP address from said communication network by ascertain- 26. A The mechanism of claim 25, said arbitrary IP 
ing whether said interworking function has provided said address message is an IPCP Configure-Nak message con- 
assigned IP address in response to said IP address negotia- taining one of a plurality of arbitrary IP addresses that said 
aons _ communication device will reject. 

20. The mechanism of claim 19, wherein, in response to 5 27. The mechanism of claim 26, wherein said ascertaining 
determining that said communication device has received whether said interworking function has assigned an IP 
said assigned IP address, said communication device trans- address . ^ response to said IP address request message is 
mits a message with said assigned IP address to said terminal determined by identifying whether sad communication 
device device has received an IPCP Configure-Ack message con- 

* , . - . . * n , . . _ . taining an IP address from said interworking function. 

21. The mechanism of claim 20. wherein, in response to 10 mechanism of claim 2? wherem ^ assi ^ 

transmitting said assigned IP address message to said ter- jp addrcss m fa m Ipcp Configure . Nak me ^ ge 
mmal device, said communication device receives an IP ^ ass igned IP address provided by said inter- 
address request message with said assigned IP addrcss from working function. 

said terminal device. 29. A The mechanism of claim 28, wherein said IP address 

22. The mechanism of claim 21, wherein, in response to is request message with said assigned IP address is an IPCP 
receiving said IP address request message with said assigned Configure-Request message containing said assigned IP 
IP address from said terminal device, said communication address. 

device transmits a message acknowledging said IP address 30. The mechanism of claim 29, wherein said message 

request message to said terminal device. acknowledging said IP address request message with said 

23. The mechanism of claim 22, wherein, in response to 20 assigned IP address is an IPCP Configure-Ack message, 
transmitting a message acknowledging said IP address 31. The mechanism of claim 30, wherein said message 
request message to said terminal device, said communica- acknowledging said receipt of said assigned IP address to 
tioo device transmits a message with configuration options said interworking function is an IPCP Configure-Ack mes- 
from said interworking function. sage. 

24. The mechanism of claim 23, wherein, in response to 25 32. The mechanism of claim 31, wherein a delay of a 
transmitting said message with configuration options from predetermined duration is introduced to reduce the number 
said interworking function, said communication device of times said communication device repeatedly transmits 
receives a message acknowledging receipt of said assigned said arbitrary IP address message and the number of times 
IP address by said terminal device to said interworking said terminal device responds with said IP address request 
function. 30 messages containing said arbitrary IP address. 

25. The mechanism of claim 24, wherein said IP address 

request message is an IPCP Configure-Request message. ***** 
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